array[0] != array + 0 ???

Quote:

---

Originally Posted by Elysia

It will return 23 since &array[1] is the address starting at the second element, which is the "2".
Atoi will the scan until it finds the end of the string, which is after the "3". So it will return 23.

---

any way to atoi only give '2' to me instead of '23'? (without placing \0 after 2)


Thanks.

Quote:

---

But as soon as you USE the pointer produced by camdados_dados + bk, you are in an equally "undefined behaviour" situation.

---

That is not true, assuming that the use is restricted to pointer arithmetic and comparison.

Quote:

---

any way to atoi only give '2' to me instead of '23'? (without placing \0 after 2)

---

In that case you may not want to use atoi() at all, but instead just array[0], or array[0] - '0' if you want the integer corresponding to that digit.

Quote:

---

Originally Posted by Milhas

any way to atoi only give '2' to me instead of '23'? (without placing \0 after 2)


Thanks.

---

No, not unless you truncate the array by replacing the '3' with 0. This is a typical way of getting only the data you want. You can simply make a copy of the current value at array[2], then replacing it with 0, calling atoi and then restoring the previous value.

Also note that laserlight's suggestion will work on individual digits, but if it's a long string in question, the truncate option may work better.

You should really not use atoi(), use strtol og strtoi instead...

Thanks! :D

Quote:

---

Originally Posted by Milhas

If i have char array[3] = "123"

and give atoi(&array[1]), atoi will give me int '2' or int '23' ?

---

There's no telling what atoi() will give you because your array isn't large enough to hold the string "123" with a null-terminator.

Without that null-terminator on the end, atoi() will plow right past the end of your string and process whatever it finds. In most cases these probably won't be valid ASCII digits and you might get the correct result, but I wouldn't rely on that.

If you're going to use a literal string in your program, don't specify the size of the array and let the compiler figure it out for you (char array[] = "123", sizeof(array) == 4).

Actually, the code wouldn't compile in the first place, and if you manually copied the string into the buffer, you'd get a buffer overrun, perhaps a crash, but otherwise the NULL char would be there, and it would still work right.

Quote:

---

Originally Posted by Elysia

Actually, the code wouldn't compile in the first place, and if you manually copied the string into the buffer, you'd get a buffer overrun, perhaps a crash, but otherwise the NULL char would be there, and it would still work right.

---

Interesting considering I just compiled it. I think perhaps you meant to say, "In Visual Studio, the code won't compile in the first place," because MinGW allows this with no errors even with -Wall and -pedantic. I assume gcc in general probably behaves the same way.

No, according to C. If the compiler compiles it, the compiler is faulty.
char[4] can't be implicitly converted to char[3].
(Don't quote me on that.)
(Btw, it's likely Visual Studio would compile it, as well, due to its poor C compiler.)

Quote:

---

Originally Posted by Elysia

No, according to C. If the compiler compiles it, the compiler is faulty.
char[4] can't be implicitly converted to char[3].
(Btw, it's likely Visual Studio would compile it, as well, due to its poor C compiler.)

---

You might find 6.7.8p32 of ISO/IEC 9899:TC2 to be of interest.

Quote:

---

EXAMPLE 8 The declaration

Code:

---

char s[] = "abc", t[3] = "abc";

---

defines ‘‘plain’’ char array objects s and t whose elements are initialized with character string literals.
This declaration is identical to

Code:

---

char s[] = { 'a', 'b', 'c', '\0' },
    t[] = { 'a', 'b', 'c' };

---

---

Pfft again, stupid C :rolleyes:

Okay... http://c-faq.com/ansi/nonstrings.html

-- Edit --
Well then. Two posts above mine huh? Where did THOSE come from!?

-- Double Edit --
Interestingly enough, the code does not compile in Visual Studio. It complains of a buffer overrun. Hehe.

I was wrong. Again, C surprises me with all the stupid things it allows.